Mechanisms for the adaptive control of service layer operations

ABSTRACT

Service Layer adaptation may be realized through one or more adaptation rules that are programmed by server administrators in a structured but flexible manner. As part of integrating the adaptive control into its operations, a Service Layer may be configured to provide the capability to receive requests in which an adaptation rule may be specified, to provide indications through response codes returned to requestors that the Service Layer is not able to process a request due to a reduced functional state, and to send a request for more server resources or move an application, a service, or a service instance to another platform.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is the National Stage Application of InternationalPatent Application No. PCT/US2019/012845 filed Jan. 9, 2019, whichclaims the benefit of U.S. Provisional Patent Application No. 62/615,043filed Jan. 9, 2018, the contents of which are hereby incorporated byreference in their entirety.

BACKGROUND

In an Internet of Things (IoT) system, a Service Layer provides manycapabilities to devices and clients that it communicates with. Thesecapabilities are the services that the Service Layer provides and mayinclude resource discovery, subscription and notification services,device management, retargeting, group operations, semantic queries, etc.In addition, some Service Layers may host resources on behalf of devicesand/or clients. The availability of these resources may requireadditional services such as resource management, authorizations, accesscontrol, time series management, event detection, transactionmanagement, interworking, etc. FIG. 1 shows an example of some of theservices offered by a Service Layer such as a oneM2M Common ServicesEntity (CSE).

Each of the aforementioned capabilities may require certain serverresources such as CPU utilization, memory, storage, bandwidth, etc.Latency, or the time it takes the server to perform a particular task,may also factor into the overall operations of the Service Layer.Various forms of latency manifest themselves within server operations,from processing a request to sending a response, database accesslatency, latency between network nodes, etc. The availability of serverresources and the amount of concurrent processing may have an impact onthe Service Layer's operations.

SUMMARY

Methods and systems are disclosed herein to enable a Service Layer toself-monitor critical Service Layer metrics and adapt its operations inan autonomous manner. The Service Layer adaptation may be realizedthrough one or more adaptation rules that may be programmed by serveradministrators in a structured but flexible manner. During adaptation,the Service Layer may return new response codes to notify requestorsthat it is running in a reduced functional state and to offer guidanceon when to resubmit a request. Exemplary oneM2M embodiments aredisclosed that show how the proposed methods and systems can be utilizedin a Service Layer deployment. As part of integrating the adaptivecontrol into its operations, the Service Layer may be configured toperform one or more of the following operations:

Provide the capability to receive requests in which an adaptation rulemay be specified. The adaptation rule may include a monitoring componentthat specifies a comparison of some Service Layer metrics against someset threshold value(s). The adaptation rule may include a commandcomponent to adapt certain operations within the Service Layer andoptionally for some set duration. One or more adaptation rules may becreated to monitor and adapt Service Layer operations;

Provide indications through response codes returned to requestors thatthe Service Layer was not able to process a request due to a reducedfunctional state. The reduced functional state may have been a result ofthe execution of one or more adaptation rules. The response may includeadditional information to adapt the operations of the requestor, forexample to resend a request at a later time; and

Send a request for more server resources or to move an application, aservice, or a service instance to another platform. The request mayinclude other information such as the conditions that caused therequest, the duration the server resources are needed for, the latencyrequirements that were not met, etc. The request may be sent to aManagement and Orchestration (MANO) System.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to facilitate a more robust understanding of the application,reference is now made to the accompanying drawings, in which likeelements are referenced with like numerals. These drawings should not beconstrued to limit the application and are intended only to beillustrative.

FIG. 1 shows a block diagram of example services offered by a servicelayer server;

FIG. 2 shows a flow chart of an example service layer server crash;

FIG. 3 shows a flow chart of an example procedure to create adaptationrules;

FIG. 4 shows a flow chart of an example method for the usage of newresponse codes;

FIG. 5 shows a flow chart of an example configuration of user prioritylevels during application entity registration;

FIG. 6 shows a flow chart of an example request containing user prioritylevels;

FIG. 7 shows a flow chart of an example of response code feedback duringCSE adaptation;

FIG. 8 shows an example user interface;

FIG. 9A shows an example system diagram of an example machine-to-machine(M2M) or Internet of Things (IoT) communication system in which one ormore disclosed embodiments may be implemented;

FIG. 9B shows an example system diagram of an example architecture thatmay be used within the M2M/IoT communications system illustrated in FIG.9A;

FIG. 9C shows an example system diagram of an example M2M/IoT terminalor gateway device that may be used within the communications systemillustrated in FIG. 9A; and

FIG. 9D shows an example block diagram of an example computing system inwhich aspects of the communication system of FIG. 9A may be embodied.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

Service layer operations may be limited by available server resourcesand processing latencies. Service Layer (SL) group operations mayrequire a large allocation of memory to process the many parallelrequests if the number of group members are large. The latency of arequest may be dependent on an external device or client's response to aretargeted request. Other requests may simply entail retrieving aresource from the Service Layer without having dependencies on externalentities or needing an abundance of server resources. These requests mayrequire minimal server resources as well as minimal processinglatencies. A Service Layer may have finite resources with which toallocate to its many capabilities and may incur different processinglatencies that depend on the SL services offered.

Service Layers may need to be readily available and be run in a somewhatautonomous manner without much intervention from a system administrator.The Service Layers may also need to process a large number ofsimultaneous requests from devices and clients. Some requests may alsobe time critical and a prompt response may be required for the intendedapplication. As a result, robust operations of a Service Layer areparamount in enabling the IoT system to operate efficiently and withoutinterruptions.

Within oneM2M specifications, both Device Configuration Function (DCF)and Device Diagnostic and Monitoring Function (DDMF) may provide a CSEwith some monitoring capabilities (see oneM2M TS-0001, FunctionalArchitecture, V3.7.0). These capabilities are mostly device centric thatthe CSE manages and focus only on configuring the device and providing astatus of the device. The capabilities, however, do not address usingthe provided metrics to adapt the operations of the CSE.

FIG. 2 shows an example of a Service Layer's operation in which requestsfrom two entities may cause the server to crash. As shown in step 1, theService Layer may already be exhibiting issues with its operations as itwas running slowly and unreliably. This can be an indication that theService Layer is overloaded and is running low on server resources. Asshown in step 2, a SL device performs a group fanout operation to updateten SL resources that are members of the group. As the individual fanoutoperations are being processed in step 3, three subscriptions aretriggered in step 4 and notifications are generated and sent to therespective recipients. As shown in step 5, a new request is received inwhich a SL application wants to perform semantic query. This new requestand the pending group request coupled with the overloaded conditions ofthe Service Layer cause the server to become unresponsive as shown instep 6, and finally, to crash in step 7. It should be appreciated thatthis is one of many scenarios that could cause the SL to becomeunresponsive and to crash. It should also be appreciated that the SLApplication and SL Device shown in FIG. 2 could both be SL Applicationsor both be SL Devices. It should also be appreciated that the problemmight not be as severe as the server becoming unresponsive and crashing.The problem might be that the SL determines that it is overloaded andmay thus not accept new requests, reject new requests, or servicerequests in a manner that is not timely.

The example of FIG. 2 highlights a common issue with all serveroperations, not just with Service Layers. The main solutions may be toincrease the hardware resources available to the server so the crash canbe avoided. Other solutions may involve installing monitoring softwareto alert server administrators to take precautionary steps of avoidingoverloading the server by performing proper maintenance. These solutionsdo address server crashes but they involve adding extra hardware whichincurs cost and the need for server administrators to review monitoringreports and take preventative measures if necessary.

A Service Layer has well defined services that it offers to devices andapplications that it communicates with. These services each have varyingrequirements of hardware resources and processing latencies. Someservices are simple and may require a small amount of memory from theserver and an access to a database. Other services may be more involvedand require a larger amount of memory, may involve processing multiplerequests, and may involve processing requests that need to be routed toremote entities outside of the control of the Service Layer. As such,these services may incur a larger loading on the Service Layer and mayeven cause a crash of the Service Layer if the server was alreadyoverloaded to begin with.

If mechanisms were available to the Service Layer to not only monitorits operations but also to adapt its operations based on the monitoredmetrics, the Service Layer may be able to prolong its operational stateand potentially avoid server crashes. These mechanisms can temporarilysuspend certain SL services from operating to prevent overloading theserver and enable the Service Layer to operate in an autonomous manner.Another benefit of the mechanisms is the extended operational state ofthe Service Layer which allows server administrators time to eitherperform server maintenance or upgrade to prevent server crashes.

The methods and systems disclosed herein may enable the Service Layer toself-monitor critical SL metrics and adapt its operations in anautonomous manner. The Service Layer adaptation may be realized throughone or more adaptation rules that may be programmed by serveradministrators in a structured but flexible manner. During adaptation,the Service Layer may return new response codes to notify requestorsthat it is running in a reduced functional state and to offer guidanceon when to resubmit a request. Exemplary oneM2M embodiments aredisclosed that show how the proposed methods and systems can be utilizedin a Service Layer deployment.

As part of integrating the adaptive control into its operations, theService Layer may be configured to perform one or more of the followingoperations:

Provide the capability to receive requests in which an adaptation rulemay be specified. The adaptation rule may include a monitoring componentthat specifies a comparison of some Service Layer metrics against someset threshold value(s). Furthermore, the adaptation rule may include acommand component to adapt certain operations within the Service Layerand optionally for some set duration. One or more adaptation rules maybe created to monitor and adapt Service Layer operations;

Provide indications through response codes returned to requestors thatthe Service Layer was not able to process a request due to a reducedfunctional state. The reduced functional state may have been a result ofthe execution of one or more adaptation rules. The response may includeadditional information to adapt the operations of the requestor, forexample to resend a request at a later time; and

Send a request for more server resources or to move an application, aservice, or a service instance to another platform. The request mayinclude other information such as the conditions that caused therequest, the duration the server resources are needed for, the latencyrequirements that were not met, etc. In one embodiment, the request maybe sent to a Management and Orchestration (MANO) System.

Adaptive control methods of Service Layer operations are disclosedherein. For example, a new SL resource is proposed in which the server'soperational metrics are exposed to server administrators and authorizedusers. This resource may provide real-time statistics of metrics thatdescribe the health of a Service Layer. Examples of these metrics willbe provided, such as CPU utilization, available memory, used memory,processing latencies, etc.

In addition, a mechanism is proposed in which server administrators orauthorized users are able to control the operations of the Service Layerbased on the provided operational metrics or user provided prioritylevels. Control in this case refers to the suspension, delay,resumption, disablement, or enablement of particular SL services oroperations. This mechanism may be realized as one or more SL resource(s)created by server administrators or authorized users to control theoperations of the Service Layer based on the operational metrics. Themechanism will propose introducing categories of service types, resourcelevels, and user priorities. Other categories may also be added toprovide for more granular control of the Service Layer. The serveradministrator or authorized user may then configure the new resource(s)using the categories of services, resource levels and priorities toeither suspend, delay, resume, disable, or enable services for certaintime durations to minimize the possibility of the Service Layercrashing.

Finally, with SL adaptation mechanisms activated, new response messagesare proposed to communicate to requestors that the Service Layer is in areduced functional state. These messages may provide indications thatthe request was validated but the Service Layer is not able to processit due to a service or operation being temporarily unavailable. Themessages can also inform the requestor to try back at a later time inorder to obtain the desired service. If enough server resources areavailable, the Service Layer may even queue the request for futureprocessing.

In addition to or as an alternative to new response messages, theService Layer may interface to a Management and Orchestration system torequest for more server resources. This request may indicate the amountof server resources required to process the request, a set duration inwhich the server resources are needed, and possibly the migration ofapplications or services to another platform.

Using the methods and systems disclosed herein, robust operations of aService Layer may be made available as much as possible and the chancethat the Service Layer overloads and crashes may be minimized. Thesemechanisms may enable the Service Layer to operate in an autonomousmanner by adapting to changes in server conditions. Note that server inthis case may refer to a cloud server, a gateway, or a device running aservice layer. By prolonging the operational state of the Service Layer,server administrators and authorized users may have more time to addressthe issues affecting the server and users. For example, other servicelayers and applications may be less likely to experience operationalissues. While the methods and systems disclosed are focused on oneM2MService Layer operations, they may also apply to other SL architecturesas well.

In order to provide for the adaptive control of a Service Layer, somemetrics may need to be available to provide insight into the operationalbehavior of the server. Table 1 shows some example metrics for a ServiceLayer. These metrics may be provided by the Service Layer or by someexternal process that monitors the server resources.

TABLE 1 Examples of Service Layer Metrics Operational Example MetricDescription Value SL CPU Percentage of available CPU utilization 90%Utilization that is currently utilized by the Service Layer SL MemoryPercentage of available memory that is 95% Utilization currentlyutilized by the Service Layer SL Storage Percentage of available storagethat is 73% Utilization currently utilized by the Service Layer SL DiskIO Percentage of time a disk is in use to 50% Utilization service a SLrequest Resource The time it takes to perform resource 500 ms Discoverydiscovery - can be specified as typical, Latency minimum, and/or maximumtime. Semantic Query The time it takes to perform semantic 1500 ms Latency query - can be specified as typical, minimum, and/or maximumtime over a certain measurement period. Database Read The time it takesto read the database  5 ms Latency (for Retrieve operations) - can bespecified as typical, minimum, and/or maximum time over a certainmeasurement period. Database Write The time it takes to write to the  15ms Latency database (for Create, Update, Delete operations) - can bespecified as typical, minimum, and/or maximum time over a certainmeasurement period. Request The time it takes to process a SL 150 msProcessing request - can be specified as typical, Latency minimum,and/or maximum time over a certain measurement period. SL Throughput Thenumber of requests received by the 322 Service Layer per second - can bespecified as typical, minimum, and/or maximum time over a certainmeasurement period. SL Error Rate The percentage rate Service Layer 0.2returns an error code indicating it was a server error Number of Numberof pending SL requests in the 32 Pending Requests processing queueNumber of Number of subscription resources 1057 SubscriptionsNotification Rate Percentage rate of sending notifications  7% ascompared to all messages sent by the Service Layer

The operational metrics listed in Table 1 can be realized as a SLresource with a list of associated attributes to correspond to themetrics listed. The resource may be owned by the Service Layer andaccessed by server administrators or authorized users. Each metric mayprovide real-time status of the underlying measurement or calculationpertaining to the operations of the Service Layer over a period of time.In addition to the real-time values, maximum and minimum values may alsobe presented for use in comparing current server operations to the bestand worst case operational metrics during the server's lifetime.Additional details may be provided with each metric, for example, aparameter that expresses the latency of an operation could also provideadditional details about the query (who requested it, the query details,etc.). It should also be appreciated that this resource might be hostedby a different service layer. For example, a gateway service layer maycreate, or announce, this resource to an M2M Server so that applicationsor services on the M2M server can monitor the resource utilization ofthe gateway. These comparisons may then be used to adaptively control SLservices as described in the next section.

In order for the adaptive control to function, SL services that can becontrolled may need to be defined. These definitions may be groupedtogether as service types that are organized into levels from criticalto optional services. Some SL services, however, may be required inorder for the Service Layer to operate and hence may not be included inthe service type levels that may be disabled. Examples of these servicesmay be Retrieve/Update/Delete of existing SL resources, securityservices, authorization and access control checks, etc.

The grouping of the SL services may depend on the impact the serviceshave on the server's operations. Factors such as server resourcerequirements including CPU and memory usage, database accesses, remoteoperations, processing latencies, etc. can help server administratorsand authorized users make a determination on which service type leveleach service is grouped into. Table 2 lists examples of some SL servicetypes that can be defined and made available for adaptive control.

TABLE 2 Examples of SL Service Types Service Type Levels Services ST1Backup service, access control creation check ST2 Device management,attribute value check ST3 Retargeting, resource discovery,notifications, long polling, archive retrieval ST4 Location,interworking, transaction, dynamic authorization, event management,announcements, remote operations ST5 Communications management anddelivery handling (CMDH), time series data, multicast, group fanout,semantic query

The example service types presented in Table 2 are grouped into fivelevels. However, more levels may be added to provide for more granularcontrol of the variety of services offered by a Service Layer. Theselevels are organized by the criticality of the services to the server'soperations, with the more critical services listed first and thereforemay be disabled last. More advanced, but optional, features may begrouped as less critical as are services that consume a lot of serverresources. The grouping of these services may also change over time asserver administrators and authorized users may find the need to increaseor decrease the level of a service depending on the requirements ofusers.

In addition to SL services, create or execute operations on certain SLresources may also impact server operations. Sometimes, a request on aresource may require certain services to operate, such as a request onthe oneM2M fanout resource triggers group operations within the ServiceLayer. Other times, a request to create certain resources may involvetriggering a SL service at some later instance in time. For example,creating a subscription resource may trigger notifications in thefuture. Similarly, creating an application resource may require futureoperations on one or more container, subscription, and/orcontentInstance resources. Some requests on a resource may merely impactoperations within the server that the SL can manage, such as creating aoneM2M contentInstance resource, which requires mainly a databaseaccess. The grouping of SL resources provides for a secondary level ofadaptive control in which create or execute operations toward certainresources may be disabled should the SL be limited in server resources.Table 3 shows some examples of how oneM2M resources may be grouped toprovide for more granular and adaptive control of Service Layeroperations.

TABLE 3 Examples of SL (oneM2M) Resource Levels Resource Levels ServicesRL1 Access control policy, contentInstances RL2 Containers,flexContainers, node, mgmtObj, mgmtCmd, execInstance RL3 Subscription,notification, schedule, request, archive resource RL4 AE, group,locationPolicy, delivery, pollingChannel, statsConfig, eventsConfig,statsCollect

As shown in Table 3 and similar to SL services, SL resources may begrouped into levels for use in the adaptive control of the server'soperations. The levels may be organized in a similar fashion as SLservices, where the most critical SL resources are listed first and havea lower resource level. These resources, such as oneM2M's ACP andcontentInstance resources, may also have minimal impacts to theoperations of the Service Layer. Other resources, such as oneM2M's AEand group resources, may require more server resources. In the case ofan AE resource, creating the resource has minimal impact at the time ofcreation but the impact may be realized in the future as the AE may thenbe able to create one or more containers, subscriptions, and even groupresources. If a SL is already low on server resources, the best courseof action may be to limit the number of users (or AEs) from accessing SLservices. By denying an AE's request, the Service Layer may be able tofocus on servicing AEs already created on the server.

Both the service type levels and SL resource levels provide for two setsof operational components used in adapting the Service Layer'soperations. However, these components focus on only two aspects of theService Layer—services and resources. A third aspect may be realized toaccount for cases in which certain requestors may have more urgent needsthan others. For example, a requestor may have a more urgent need to getnotifications, such as if the requestor is a doctor who is monitoring apatient in critical condition at a hospital. On the other hand, a sensordevice may have been recently upgraded to provide a new measurement inwhich a container resource needs to be created. In this case, ifresource level 3 from Table 3 is disabled, the doctor may not be able toreceive notifications, while the sensor may be able to create thecontainer for the new measurement. This third aspect accounts for theService Layer to process user priority levels. Having a thirdoperational component can provide for even more granular control ofoperations in such cases. As needs arise, even more components may beadded and what these components are may be deployment or serverspecific. In addition to user priority, other components may be based onthe importance of the data that is associated with the operation, thesecurity that is required for the data that is associated with theoperation, and how much time has passed since the data that isassociated with the operation was updated or accessed.

Using the operational components set forth in the preceding tables, astructured expression may be crafted to form the basis for adaptingcontrol of a Service Layer. This expression, herein referred to asadaptation rules, may have a monitoring component and a controlcomponent and have the form:If(metric)(operator)(threshold)(time window),→monitoring(command)[server operations] for(duration)→control

where:

metric Service Layer metric being monitored, examples in Table 1operator Relational operators such as >, <, =, >=, <=, !=, etc.threshold A value associated with the Service Layer metric time Aparameter where a time window may be added to window indicate when themonitoring is enabled; outside the time window, no monitoring isperformed command Adaptive command such as enable, disable, suspend,resume, etc. server The server operations that are being controlled,such as the operations service types from Table 2, the resource levelsof Table 3, and user priority levels, e.g. levels 1 to 10. Thisparameter may contain a list of operations or services of the ServiceLayer. duration A duration usually specified in time units the adaptivecontrol is applied to the server's operations. The duration may also bespecified as a conditional expression in which certain metrics must meeta certain threshold value in order for the adaptive control to beremoved, e.g. serverMetric < thresholdValue.

The monitoring component of the adaptation rule may comprise comparisonsof the current value of a metric against threshold values determined tocause issues with the operations of the Service Layer. Additionally oralternatively, the current value may be compared against either theminimum or maximum value for that metric. An optional time window may beadded to limit when the comparison is performed—within the window,monitoring is enabled; outside the window, no monitoring is performed.The threshold value may be updated to provide flexibility in creatingthe comparisons. For example, at initial deployment of a Service Layer,a server administrator may configure an initial threshold that isaggressive for a particular metric to ensure the server can support asmany users as possible. If and when the performance of the server isimpacted by an abundance of users later, the administrator may need todecrease the threshold value to prevent the possibility of a servercrash. Decreasing the threshold value also affords server administratorsadvance warnings with which they may have more time to address anypotential issues with the server's operations.

The control component describes what may need to be performed to adaptthe Service Layer's operations and for what time duration, if any. The“(command)” parameter is a command that determines what operationalbehavior to take in response to the metric exceeding the thresholdvalue. This command may be to disable, delay, suspend, resume, or enableparticular operations of the Service Layer. The “[server operation]”parameter indicates the services and/or operations that are affected bythe command. This parameter may have multiple references to differentserver operations that will be described later. Finally, the optional“(duration)” parameter determines the time duration the command takeseffect in controlling the operations of the server. This parameter maybe specified as a set time duration, as a null value to signify aninfinite period, or as an operational metric that controls the durationof the adaptation.

The “[server operations]” may be divided further as a sub-expression inwhich the different operational components are factored into the fullexpression. For example, “disable [ST3, not RL3, (UPL>5)]” may beinterpreted as disable all the services listed in ST3 (and above) butnot for creating resources in level 3 (and below) and only for userpriority levels (UPL) greater than 5. In other words, all services atST3 level and above (ST3 to ST5) and all requests with a UPL greaterthan 5 (UPLs 6 to 10) are disabled but creating resources in RL3 levelsand below (RL1 to RL3) are allowed. Note the composition andinterpretation of the sub-expression for server operations may beimplementation dependent as the operational components of servers may bedifferent from each other.

The user priority levels (UPL) are levels that may be assigned by theService Layer for all requestors in the system. These priority levelsmay be specified within a range, such as 1 to 10 with one being thehighest priority, and sub-ranges may be assigned to each individualrequestor, e.g. 7 to 10. The UPL may be assigned as a policy during theonboarding process of a device, during the device's registrationprocedure, or some other service subscription mechanism. The policy maybe finely grained in which services and resources are assigned prioritylevels. Additionally or alternatively, it may be unconstrained and onlyindicate a range of priority levels in which the requestor may use inmaking requests.

When combined together, the full expression describes conditions in theService Layer such that when it is detected, some operations of theserver are affected, possibly for a set duration. The monitoringcomponent of the expression may detect the server condition that is ofinterest. When the condition triggers, the control component maydetermine what needs to be performed. For example, a particular serviceor operation may be suspended. Finally, if a duration is specified, thesuspended service may resume operations after the set duration haselapsed.

The entire expression, therefore, may form the adaptation rules serveradministrators or authorized users may use to configure how the SLadapts to changes in the utilization of SL resources. These rules may beconfigured to monitor the operational metrics of the Service Layer andadapt control of the SL's operations by either disabling or suspendingservices or enabling or resuming services as necessary. The operationsof the Service Layer can then adapt to changes in server resources so asto avoid sluggish operations or even a server crash. This adaptation mayensure the Service Layer is available but with a reduced functionalscope.

The adaptation rules can be created individually and at different timesdepending on the needs of the Service Layer. As the serveradministrators or authorized users learn the behaviors of the serverunder certain conditions, more rules may be added. Collectively, therules may then monitor all aspects of the SL's operations and adapt theoperations of the SL services as specified. The adaptation rules may berealized as a resource within the Service Layer to allow serveradministrators and authorized users the ability to configure and updatethe rules to dynamically control server operations.

Example methods for how the service layer might respond to requests fromother service layers and applications during SL adaptation, which is thereduced functional state of the Service Layer, are described below.

With the ability to adapt operations of the Service Layer in place, amechanism may be added to inform requestors that certain services oroperations are temporarily unavailable and if possible, indicate a timethe service or operation may be made available in the future. Thismechanism is important to distinguish the case in which a service is notavailable at all (when the Service Layer does not support a particularservice) to the case in which the Service Layer does support a servicebut has temporarily suspended its operations. Table 4 shows some exampleresponse codes a Service Layer may include in a response message toprovide an indication of its reduced functional state.

TABLE 4 Examples of New SL Response Codes New Response Code DescriptionSERVICE_TEMPORARY_UNAVAILABLE The required service is temporarilyunavailable, try again later. The request was validated but the servercannot process the request at this time. If possible, a time may beprovided to indicate when the service will be available.REQUEST_CANNOT_BE_PROCESS The Service Layer is in a reduced functionalstate and cannot process the current request. The request was validatedbut the server cannot process the request at this time. The reason maybe indicated by a resource level (RL) or a user priority level (UPL)that are temporarily unavailable. Additional information about why therequest may not be processed may also be included. If possible, a timemay be provided to indicate when the request may be able to beprocessed. REQUEST_QUEUED_RESPONSE_LATER The request has been validatedand queued by the Service Layer and will be processed at a later timewhen the appropriate service is available. A temporary ID may beprovided in the response so the requestor can perform request-responsematching. Alternatively, a URI may be provided to indicate where theresponse may be stored within the Service Layer. If possible, a time maybe provided to indicate when the response or another status update maybe returned. ACCESS_DENIED_PRIORITY_LEVEL If a UPL is provided by therequestor and the value is outside the range of the adapted value, theSL returns this error. This error is also returned for cases in which apolicy is configured for user priority levels of the requestor that isoutside the range of the current adapted UPL. SERVER_BUSY_TRY_AGAIN TheService Layer is in a very limited operational state and cannot processthe request at this time, try again later. No validation of the requestis performed. If possible, a time may be provided to indicate when theService Layer may be available again.

Each of the response codes listed in Table 4 may be used whenever aService Layer adaptation is in effect and the required service orfunction is not available. In other words, the response codes in Table 4may be triggered by the activation of one or more adaptation rules.During normal operations without any adaptation, these response codesmay not be used as the services required are available to process therequest.

The response code returned depends on the state of the Service Layerwhen the request is being processed. The state of the Service Layer isdetermined by executing one or more adaptation rules. The response codeSERVICE_TEMPORARY_UNAVAILABLE may be returned when a particular servicethat is required to process the request has been disabled or suspendedand is currently not available. If the adaptation rule that disabled orsuspended the service provided a time duration, then that time durationcan be included with the response code to indicate when to retry therequest. As stated before, this response code may be used todifferentiate from the case in which the service is not implemented bythe Service Layer.

The response code REQUEST_CANNOT_BE_PROCESS may be used whenever anadaptation rule has specified that either a resource level (RL) or otherSL operational component has been suspended. This response code mayindicate the Service Layer is in a reduced functional state and cannotprocess the request. If a time duration was specified in the adaptationrule, that value may be included in the response as well. Finally, theresponse message may also include information on what prevented theService Layer from processing the request.

In cases where the Service Layer is able to queue up the request but isnot able to process it until a later time, the response codeREQUEST_QUEUED_RESPONSE_LATER may be returned to the requestor. Atemporary ID may be returned with the response code for use inrequest-response matching. In one embodiment, the ID may be a URI thatspecifies where the response will be stored in the Service Layer forlater retrieval. If the Service Layer has information on when theresponse may be returned, that information may be added to the responsemessage. When the Service Layer is ready to send the response, thetemporary ID may be included so the requestor can identify that thisresponse is for a previous request.

For cases where the ACCESS_DENIED_PRIORITY_LEVEL response is returned,the Service Layer may be indicating that the request is not able to beprocessed due to having insufficient user priority levels for therequest. The user priority levels may be retrieved from a policy thatwas assigned by the Service Layer as previously described or specifiedexplicitly in the request. Either way, the priority level provided orretrieved may be outside the range of the currently adapted prioritylevel that the Service Layer is operating with.

The SERVER_BUSY_TRY_AGAIN response code may be returned in cases wherethe Service Layer is in a very limited operational state and cannotprocess the request. This response code may reflect an extreme state ofthe operations of the Service Layer that the request is not evenvalidated. The response code may indicate an imminent need for serveradministrators to address the issues with the Service Layer before theserver crashes. For example, this response code may be returned ifService Layer operations are limited to ST1 from Table 2 and RL1 fromTable 3. Notifications may also be automatically generated and sent toserver administrators to indicate the severity of the issue with theService Layer.

Examples for how the proposed methods and systems are used throughprocedural interactions with the Service Layer are described below. Atdeployment, a Service Layer may have exposed the operational metrics ofthe server as a resource. Adaptation rules may then be created using themetrics and the service types and resource levels shown in Table 2 andTable 3, respectively. In addition, user priority levels 1 to 10 areavailable for assigning to user requests. The Service Layer may assignthese UPLs based upon information in a requestor's service profile.Alternatively, a requestor may be assigned a range of UPLs with which tomake requests with and may use different RPLs dependent on the need of aparticular request.

Once a Service Layer is deployed and its operational metrics areavailable, server administrators may then create adaptation rules thatadapt server operations as needed to help prevent server crashes. FIG. 3shows an example procedure in which a server administrator, realized asa SL Application, creates an adaptation rule on the Service Layer. Thefollowing descriptions describe in detail the steps of FIG. 3.

In step 1, at deployment, the operational metrics of the Service Layermay be exposed as an addressable resource. The resource may contain oneor more of the attributes shown in Table 1.

In step 2, a SL application acting the part of a server administratorthen proceeds to create an adaptation rule on the Service Layer. TheopControl resource that is requested to be created may contain thefollowing rule (note the parenthesis symbol are used as delimiters inthe expression:If(memUt>90%)(M-F 09:00,17:00), suspend(ST4,RL3,UPL7) for 30 mins

The expression states “if memory utilization is greater than 90% and thecurrent time is between 9:00 am to 5:00 pm every work day (i.e.Mon-Fri), suspend service types 4 or greater, resource levels 3 orgreater, and user priority levels 7 or greater.” This particular rule isonly concerned with monitoring memory utilization during typical workweek hours and only if the memory usage is high. Any requests thatrequire one of the services listed in Table 2 for ST4 or greater, orresources in Table 3 for RL3 or greater, or has a user priority level of7 or greater, may be denied service by the server. An alternative way torepresent the rule is as follows:If(memUt>90%)(M-F 09:00,17:00), suspend(ST>4,RL>3,UPL>7) for 30 mins

In this case, the service types, resource levels, and user prioritylevels are specified explicitly using relational expression.

In step 3, the Service Layer validates the request to ensure allrelational expressions have matching data types. In addition, theService Layer may also compare the current rule against existing rulesto determine if there are any conflicts.

In step 4, an appropriate response is sent from the Service Layer to theserver administrator. The Service Layer may also include a rule ID orother name to identify the rule that was created. If there was aconflict with an existing rule, the Service Layer may include the nameof the conflicting rule in the response.

The adaptation rules may also be updated by the administrator should theneed arise. The update may be triggered by reports of sluggishoperations of the Service Layer by users or tests performed by theserver administrators or authorized users. The rules themselves may havebeen created with threshold values that were either too large or toosmall. To update a rule, the server administrator or authorized user mayneed to send a request targeting the rule using either an ID or resourcename and provide the attribute and the corresponding value. The ServiceLayer may check against existing rules to ensure no conflicts arepresent. Adaptation rules may also be deleted if they are no longerneeded.

Once adaptation rules are created and activated, the Service Layer mayprovide status of reduced functionality in responses to requests thatare not able to be processed. These new response codes may be usedduring such adaptation so requestors know that the Service Layer iscapable of processing the request but is currently unable to. Except forthe SERVER_BUSY_TRY_AGAIN response code, all other response codes listedin Table 4 at least indicate the request was validated and ready to beprocessed. FIG. 4 shows examples of three uses of these new responsecodes.

The following descriptions describe in detail the steps of FIG. 4:

In step 1, the Service Layer is operating in adaptation mode in whichservice types 3-5 of Table 2, resource levels 3-4 of Table 3, and userpriority levels greater than 7 are all disabled.

In step 2, a SL device submits a request to create an applicationresource.

In step 3, the Service Layer processes the request and checks therequest against the adaptation rules that are currently active. TheService Layer detects that the application resource is listed as a RL4resource. As a result, the Service Layer returns aSERVICE_TEMPORARY_UNAVAILABLE response code to the SL device. In thiscase, the Service Layer also informs the SL device that the ServiceLayer may be able to process the request in 60 minutes. The ServiceLayer may also generate a report, such as a charging record to recordthat an operation has been delayed or disallowed. The report may be sentto the MANO system so that the MANO system may consider dedicating moreresources to the service layer.

In step 4, a SL application is trying to execute a device management(DM) operation to retrieve some information about a device it isinterested in. The request is not critical and hence an UPL value of 8is included.

In step 5, the Service Layer then evaluates the request and checks therequest against the adaptation rules that are currently active. A UPLvalue is found in the request and its value is compared to theadaptation rule that all RPLs>7 be denied access due to the operationalstate of the server. As a result, the Service Layer returns aREQUEST_CANNOT_BE_PROCESS response code to the SL device. Similar tostep 3, the Service Layer also informs the SL application that theService Layer may be able to process the request in 60 minutes.

In step 6, during the next 60 minutes, the Service Layer is able torecover and adapt its operations to include support for processing bothST3 services and RL3 resources. However, the Service Layer may stillonly be able to process UPL 7 and higher priority requests.

In step 7, the SL application sends another DM request but this time,the request is more urgent and the UPL is set to 7.

In step 8, the Service Layer processes the request and checks therequest against the adaptation rules that are currently active. Therequest passes the adaptation rules check but the server is unable tocompletely process the request. The server returns aREQUEST_QUEUED_RESPONSE_LATER response code to the SL application andprovides an ID for the application to use in request-response matching.When the Service Layer is able to send the response, it may include thisID along with the information requested.

In cases where one of the response codes listed in Table 4 and a timeduration is provided in a response to a request, the Service Layer maybe indicating that the request may be successfully processed if it issent after the indicated time duration. SL devices should heed theindication and wait until the time duration has elapsed before sendingthe same request to the Service Layer again. If the SL device sends thesame request before the appropriate time has elapsed, the Service Layermay return the same response but with a reduced time duration for whenthe service may be available. Note that the Service Layer may also lowerthe user priority levels assigned to the SL device in such an instance.

For the case that a REQUEST_QUEUED_RESPONSE_LATER is returned, theService Layer may be indicating that the request has been queued and itwill be processed at a later time. The ID that is returned may be usedto identify the response that results from the Service Layer processingthe request. No further action may be required from the SL device—itjust needs to save the ID for request-response matching purposes.Additionally or alternatively, the ID may be a URI that is returned toindicate where the response will be stored in the Service Layer. The URImay be accompanied by an expected time the response will be available.

The Service Layer may handle overloaded conditions by disallowingcertain types of operations, delaying certain types of operations,and/or prioritizing particular users differently. Additionally oralternatively, the Service Layer may take other, or additional, actionsto mitigate congestion situations. For example, the Service Layer couldsend requests to a MANO System indicating the need for more storage,more memory, more CPU cycles, lower latency storage, and/or lowerlatency memory. The Service Layer may perform the mitigation actionsdescribed herein until the MANO System indicates that the requestedresources can be provided.

The request from the Service Layer to the MANO System may include whattypes of server resources are needed, how long the server resources areneeded, what caused the request (e.g., current resource utilization),etc. The response from the MANO System may indicate whether therequested server resources will be provided, when they will be provided,how long they will be provided for, a cost association with the service,a transaction identifier to store in charging records so that chargingrecords can be correlated later, and how much of the specific serverresources are being allocated.

The request to the MANO system may also indicate that an instance of anapplication, service layer, or service is not currently meeting itslatency requirements and thus should relocate to a different physicalplatform in order to meet its latency requirements. For example, theprocedures described herein may be used to detect that latency betweentwo endpoints is not acceptable or is increasing and may soon becomeunacceptable. The request to the MANO System may indicate what two endpoints are communicating, what their latency requirements are, and whichend points may be relocated. In response to the request, the MANO Systemmay move an instance of an application, service, or service layer. Forexample, an application that was hosted on one small cell platform maymove to another small cell platform that is geographically closer to theother endpoint (e.g., application) that may be hosted on a device.Moving the application, service, or service layer instance may involvethe MANO System providing the Service Layer with a new Point of Access(PoA) for the application, service, or service layer instance and theService Layer providing the PoA to the other end point (possibly via anotification).

Example embodiments are described below to demonstrate how the adaptivecontrol of service layer operations can be applied to a Service Layersuch as that of a oneM2M CSE (see oneM2M TS-0001, FunctionalArchitecture, V3.7.0). Example embodiments of the proposed methods andsystems as applied to the oneM2M standard are described below. NewoneM2M attributes, resources, and response codes are shown to realizethe different aspects of adapting the operations of a CSE.

The user priority levels proposed herein can be realized as oneM2Mattributes for either the <AE> or <CSE> resource. An <AE> or <CSE> canspecify a desired range of priority levels upon registration if it isaware of the possible values. Additionally or alternatively, the<m2mServiceSubscriptionProfile> resource may be able to provide thesepriority levels and the CSE can use the pre-provisioned values to assignthem to AEs and CSEs at registration.

The user priority levels may be used to override certain SL adaptationcontrols that are in effect at the time the request is made. TheuserPriorityLevels attribute of an <AE> or <CSE> resource may be usedimplicitly or explicitly by the requestor during such adaptation. Forexample, an <AE> may have a userPriorityLevels attribute specified as“createContainer=5, multicast=10, notification=3” where user priorityranges from 1 to 10 with 1 being the highest priority. In this case,when an AE sends a request to create a container, the CSE may apply aUPL of 5 to the request. This is an implicit application of the UPLattribute. In an example explicit application, the AE may provide theUPL in the request directly. In this case, the CSE may use theexplicitly provided UPL instead of the one provided in the <AE>resource.

TABLE 5 Proposed oneM2M AE or CSE Attribute Attribute Name DescriptionuserPriorityLevels A complex type that has an assigned priority levelassociated with certain services and/or resources to indicate what userpriority level should be used for requests targeting such services. AUPL range without the associated services may indicate the requestor hasthe ability to specify individual UPL values on a per request basis. Forexample, a range of [5-10, 7] indicates the requestor can submitrequests with UPL values explicitly between 5 and 10. In the absence ofa UPL in the request, the default value of 7 is used.

A CSE's operational metrics may be realized as a new oneM2M resourcecseMetrics. This resource may be located under the <cseBase> resource,under a <node> resource associated with the CSE, or in another locationwithin the CSE's resource tree. If located under the <node> resource,cseMetrics may be a specialization of the <mgmtObj> resource type. Theoperational metrics for the CSE may then be the attributes of thecseMetrics resource. Table 6 shows examples of operational metrics thatmay be used to quantify the state of the CSE's operations. Theseattributes may have Read Only (RO) access as the values presented may begenerated by the CSE itself and cannot be modified by external users.

TABLE 6 Proposed oneM2M cseMetrics Resource Attributes Attributes of<cseMetricsAnnc> <cseMetrics> Multiplicity RW/RO/WO DescriptionAttributes Universal and common * * See clause 9.6.1.3 of oneM2MTS-0001. OA attributes resDiscLatency 0 . . . 1 RO The time it takes toperform resource OA discovery. This may be presented as an average time(calculated by the time resource discovery response was sent minus thetime the request was received), a minimum time, and/or a maximum time.semanticQueryLatency 0 . . . 1 RO The time it takes to perform semanticOA query. This may be presented as an average time (calculated by thetime semantic query response was sent minus the time the request wasreceived), a minimum time, and/or a maximum time. dBReadLatency 0 . . .1 RO The time it takes to read the database. OA This may be presented asan average time (calculated by the time database query was receivedminus the time the database query was sent), a minimum time, and/or amaximum time. dBWriteLatency 0 . . . 1 RO The time is takes to write tothe OA database (for Create, Update, Delete operations). This may bepresented as an average time (calculated by the time database write wasreceived minus the time the database write was sent), a minimum time,and/or a maximum time. requestProcessingLatency 0 . . . 1 RO The time ittakes to process a CSE OA request. This may be presented as an averagetime (calculated by the time CSE response was sent minus the time theCSE request was received), a minimum time, and/or a maximum time.throughput 0 . . . 1 RO The number of requests received by the OA CSEper second. This may be computed as a moving average of receivingincoming requests over a time period such as 30 minutes, which may beimplementation dependent. errorRate 0 . . . 1 RO The percentage ratethat the CSE OA returns an error code indicating it was a server error(i.e. 5xxx). This may be a ratio of the number of error responses to thetotal number of successful responses sent by the CSE over a certain timeperiod, such as 30 minutes. Note error messages due to adaptive controlof the CSE may not be considered error responses. However, this may beimplementation dependent. numPendingRequests 0 . . . 1 RO Number ofpending CSE requests in OA the processing queue. This value is a runningtotal of all pending requests that have not been sent a response by theCSE. numSubscriptions 0 . . . 1 RO Number of subscription resources.This OA is a dynamic value that shows the total number of createdsubscription resources. The total includes deletions of subscriptionrequests. notificationRate 0 . . . 1 RO Percentage rate of sendingnotifications OA as compared to all messages sent by the CSE. This maybe computed as the ratio of the total number of notifications sent bythe CSE to the total number of all messages sent by the CSE over acertain time period, such as 30 minutes.

The adaptive control to the CSE's operations may be realized through thecseAdaptRule resource. This resource may be located in the same locationas the cseMetrics resource, for example as child resources of <node>, oras a child resource of the cseMetrics resource. Alternatively, anattribute may be added to the cseAdaptRule resource to link to acseMetrics resource and the cseAdaptRule may be located elsewhere in theresource tree. One or more cseAdaptRule resources may be created tospecify different adaptation rules for controlling the CSE. Table 7shows example attributes for the cseAdaptRule resource in whichadaptation rules may be created.

TABLE 7 Proposed oneM2M cseAdaptRule Resource Attributes Attributes of<cseAdaptRuleAnnc> <cseAdaptRule> Multiplicity RW/RO/WO DescriptionAttributes Universal and * * See clause 9.6.1.3 of oneM2M TS-0001. OAcommon attributes ruleID 1 RO An identifier assigned by the CSE toidentify OA the adaptation rule specified by the following attributes.metricLinks 1 (L) RW URI(s) of CSE metric resources in which this OArule is linked to. opMetrics 1 (L) RW A relational expression comparinga CSE OA metric against some threshold value. The format is: metric [>,<=, >=, <=, !=] thresholdValue Metric is provided by a cseMetricsattribute that is linked using the cseMetricLink attribute. Whenmultiple expressions are provided, all expressions must be satisfied inorder for the command to be applied, i.e. the expressions are ANDedtogether when they are evaluated. timeWindow 0 . . . 1 RW Two timevalues that form a window in which OA metric monitoring is enabled;outside the time window, no monitoring is performed. The format of thetime values may be: 1) 12:00pm-3:00pm 2) 12:00-15:00 3) M 22:00, Tu 7:004) M-Tu 18:00-00:00 In both 1) and 2), the time window is from 12:00pmto 3:00pm. In 3), the time window is Mon 3:00pm to Tues 7:00am while in4), the time window is on Mondays and Tuesdays from 6:00pm to midnight.command 1 RW A command used to adapt CSE operations OA based on asuccessful comparison of the CSE metric against a threshold value.Commands may be enable, disable, suspend, resume, etc. The command maybe applied to the features, resources, and userPriorityLevelsattributes. features 1 (L) RW A list of features in the Features Catalogthat OA the command attribute applies to. For example, “disable {group,registration}” would disable group and registration services so requestsneeding these services may temporarily be denied. resources 0 . . . 1(L)     RW A list of new resource instances that the OA commandattribute applies to. For example, “disable {AE, subscription}” wouldprevent any requests from creating an AE or subscription resourceinstance while the CSE is in a reduced functional state and theassociated adaptation rule is in effect. userPriorityLevels 0 . . . 1 RWA relational expression that specifies what OA user priority levels thecommand attribute applies to. For example, the expression (UPL > 7)specifies that user priority levels above 7 are disabled if command =disable. duration 0 . . . 1 RW A relative time that specifies theduration the OA CSE operations that will be adapted based on thecommand. A null value or an “inf” value may signify an indefiniteduration. Alternatively, the duration may be specified as a relationalexpression that specifies some metrics must meet a certain threshold inorder for the rule to be deactivated. For example, an expression such as“throughput < 50%” may be used for this attribute.

The following response codes are proposed to be added to the oneM2Mresponse codes (see oneM2M TS-0004, Service Layer Core Protocol,V2.5.0). Table 8 shows the new response codes being added to the 5xxxseries codes for the Receiver Error response class. These response codesare grouped together into the 53xx sub-class to differentiate them fromthe existing response codes. These response codes may be used toindicate that the CSE is running in a reduced functional state.

TABLE 8 New oneM2M Response Codes Numeric Code Description 5000INTERNAL_SERVER_ERROR 5001 NOT_IMPLEMENTED 5103 TARGET_NOT_REACHABLE5105 NO_PRIVILEGE 5106 ALREADY_EXISTS 5203 TARGET_NOT_SUBSCRIBABLE 5204SUBSCRIPTION_VERIFICATION_INITIATION_FAILED 5205SUBSCRIPTION_HOST_HAS_NO_PRIVILEGE 5206NON_BLOCKING_REQUEST_NOT_SUPPORTED 5207 NOT_ACCEPTABLE 5208DISCOVERY_DENIED_BY_IPE 5300 SERVER_BUSY_TRY_AGAIN 5301SERVICE_TEMPORARY_UNAVAILABLE 5302 REQUEST_CANNOT_BE_PROCESS 5303REQUEST_QUEUED_RESPONSE_LATER 5304 ACCESS_DENIED_PRIORITY_LEVEL

The following procedures demonstrate how the oneM2M system can berealized with the methods and systems proposed herein. A CSE may have aCSEBase name “CSE01” and a cseMetrics resource may be created under CSEbase during deployment. The cseMetrics resource may have a URI“/CSE01/cseMetrics” and access to cseMetrics may be provided to CSEadministrators. The cseAdaptRule resources may be created under “/CSE01”or alternatively, they may be child resources of the cseMetricsresource. In this case, the cseMetricLink attribute shown in Table 7 maybe omitted.

During AE registration, the user priority levels may be configured foran AE and similarly for a CSE during CSE registration. An AE can includethe userPriorityLevels attribute in the AE registration if it wasprovisioned with a policy during the onboarding procedure. Additionallyor alternatively, CSE01 may obtain user priority level information froma <m2mServiceSubscriptionProfile> resource for the AE.

The following descriptions describe in detail the steps of FIG. 5:

In step 1, during AE registration, AE2 may include a policy for theuserPriorityLevels attribute if it was provisioned with one. The policymay provide a range of user priority levels AE2 can use to make requestswith explicitly. Additionally or alternatively, the policy may be morefine grained and describes different priority levels for differentservices and resource requests.

In step 2, CSE01 processes the registration request and assignsappropriate user priority levels if available. In the absence of theuserPriorityLevels attribute in the request, CSE01 may also obtain thepolicy from a <m2mServiceSubscriptionProfile> or other similar resourceassociated with AE2.

In step 3, if registration was successful, CSE01 returns the policy ofthe user priority levels that have been assigned to AE2 along with theresponse code.

Once a userPriorityLevels policy has been configured, AE2 may then useone of the assigned user priority levels in future requests to CSE01. Ifthe policy provides specific priority levels for certain services orresources, future requests may use the implicit method of specifyinguser priority levels. CSE01 may check the policy provided in theuserPriorityLevels attribute associated with AE2 to evaluate access tothe targeted services or resources. AE2 may also provide theuserPriorityLevels explicitly in the request. FIG. 6 shows an example ofboth cases in operation.

The following descriptions describe in detail the steps of FIG. 6:

In step 1, CSE01 is under adaptive control and currently has disabledprocessing requests with UPL greater than 7. AE2 had previouslyregistered with CSE01 and was provisioned with a userPriorityLevelspolicy in which creating a container resource was assigned a range ofUPLs between 7 to 10 and with a default value of 9. The default UPLvalue is applied to AE2's create container requests where no UPL areexplicitly specified. However, AE2 can override this default value byincluding a userPriorityLevels attribute in the create request that isbetween UPLs of 7 to 10.

In step 2, AE2 sends a create container request in which no UPL isprovided.

In step 3, CSE01 processes the request and evaluates the UPL associatedwith AE2 against the adapted UPL. The comparison shows that AE2's UPLfor this request (create container) is 9, which is greater than theadapted UPL of greater than 7. As a result, the request is denied.

In step 4, CSE01 returns an ACCESS_DENIED_PRIORITY_LEVEL code in theresponse. The response also includes the priority levels that arecurrently disabled by CSE01 and may include the default UPL used inevaluating the request for AE2.

In step 5, AE2 sends another create container request but this time witha UPL of 7.

In step 6, CSE01 process the request and checks the provided UPL againstthe adapted UPL. The validation is successful and CSE01 allows therequest to be processed to completion.

In step 7, CSE01 returns a Created response.

Note that AE2 may be limited to specify a UPL value in step 5 that iswithin range of the values provisioned to its userPriorityLevelsattribute during AE registration. Specifying a value outside this rangewill result in a CONTENTS_UNACCEPTABLE response code being returned. TheCSE may also include the acceptable range in the response. In this case,the UPL value provided is outside the range provisioned to AE2 andhence, the contents of the request may not be acceptable.

Once CSE01 is under adaptive control, it can provide indications of whennormal operations may resume along with the response code. FIG. 7 showsan example call flow in which CSE01 notifies AE2 of the anticipated timenormal CSE operations may resume. In this case, CSE01 is under adaptivecontrol where the Group feature is disabled. Note the following callflow does not show all the checks CSE01 performs when evaluating arequest such as message validation and access control checks.

The following descriptions describe in detail the steps of FIG. 7.

In step 1, CSE01 is under adaptive control and currently has disabledprocessing group requests.

In step 2, AE2 sends a create group request.

In step 3, CSE01 processes the request and performs an adaptive controlcheck to determine if the request is allowed.

In step 4, CSE01 returns a response with the REQUEST_CANNOT_BE_PROCESScode along with the expected time that the group processing feature willbe enabled. In this case, 57 minutes remain until CSE01 can processgroup requests again.

In step 5, after some time, AE2 sends another create group request.

In step 6, CSE01 processes the request and performs an adaptive controlcheck to determine if the request is allowed.

In step 7, CSE01 returns a response with the REQUEST_CANNOT_BE_PROCESScode along with the expected time that the group processing feature willbe enabled. In this case, only 2 minutes remain until CSE01 can processgroup requests again.

In step 8, the adaptive control period is over and CSE01 resumes normaloperations.

In step 9, AE2 sends a create group request.

In step 10, CSE01 allows the request to be processed since adaptivecontrol has expired.

In step 11, CSE01 returns a Created response if the request wasprocessed successfully.

The CSE adaptation may be triggered by the activation of one or moreadaptation rules. These rules may be realized as cseAdaptRule resourcesthat CSE administrators create to adapt the operations of the CSE tochanging system conditions. These adaptation rules may contain amonitoring component and a command component, which adapts theoperations of the CSE. The monitoring component may depend onoperational metrics provided for the CSE. Table 9 shows two examples ofoperational metrics that may be available in a CSE. The hwMetricsresource provides hardware centric metrics such as CPU utilization andmay be represented as percentages of available server resources. ThecseMetrics resource provides CSE specific metrics that describes theloading of the CSE. Each metric may be represented as a triple in theform of [minimum,current,maximum].

TABLE 9 Examples of Operational Metrics for a CSE hwMetrics cseMetricsURI: /cse01/hwMetrics URI: /cse01/cseMetrics cpuUtilization = [10, 32,74] resDiscLatency = [3, 21, 59] memUtilization = [43, 57, 73]semanticQueryLatency = [75, 202, 503] storUtilization = [10, 22, 32]dBReadLatency = [5, 11, 22] diskIOUtilization = dBWriteLatency = [20,33, 47] [27, 35, 42] reqProcessingLatency = [10, 47, 500] throughput =[28, 73, 84] errorRate = [0.1, 0.2, 0.3] numPendingRequests = [3, 25,41] numSubscriptions = [48, 73, 101] notifRate= [11, 15, 23]

Using the metrics shown in Table 9, CSE administrators can createadaptation rules that monitors and adapts the CSE's operations asneeded. Table 10 shows an example cseAdaptRule resource in which the CSEis programmed to monitor memory usage. The name opRule1 is given to thisresource and the CSE assigns a rule ID of “rid01” to the resource. Therule is monitoring the memUtilization attribute provided by thehwMetrics resource and specifies that if the current memory utilizationexceeds the maximum memory utilization by 10%, the CSE should suspendboth the group fanout and semantic query services. This monitoring isonly performed within a time window of 7:00 am to 10:00 pm daily fromMonday to Friday. In addition, all requests with user priority levelsgreater than 8 are denied access until the rule expires, which isconfigured for 60 minutes.

TABLE 10 Example Adaptation Rule 1 opRule1 ruleID rid01 metricLink/cse01/hwMetrics opMetrics curr(memUtilization) − max(memUtilization) >10 timeWindow M-F 7:00-22:00 command suspend services group fanout,semantic query resources null userPriorityLevels upl > 8 duration 60mins

Table 11 shows a second adaptation rule example in which the CSE ismonitoring that if both CPU and memory utilizations are above 90%, theCSE will adapt operations to suspend services such as group fanout,remote operations, transaction management, etc. In addition, the oneM2Mresources listed for the resources attribute are denied access forcreate or execute operations and all requests with UPL values above 5are also denied access. This adaptation is temporary and has a 5-minuteexpiration time. All suspended services, resources, and UPLs will resumeoperations after 5 minutes.

TABLE 11 Example Adaptation Rule 2 opRule2 ruleID rid02 metricLink/cse01/hwMetrics opMetrics cpuUtilization > 90, memUtilization > 90timeWindow null command suspend services group fanout, semantic query,CMDH, remote operations, transaction, . . . resources group,pollingChannel, subscription, statsCollect, . . . userPriorityLevelsupl > 5 duration 5 mins

The adaptation rules may use multiple metric resources as shown in Table12. This rule uses the metrics provided by both hwMetrics and cseMetricsresources. In this case, all the attribute names must be unique from oneanother. This rule is monitoring 4 metrics, 3 of which are associatedwith the database and the fourth metric monitors if the requestprocessing latency is taking too long to process incoming requests. Eachof the monitored metrics must be valid in order for the rule to beactivated. Finally, the rule has a relational expression for theduration attribute, which states that opRule3 will resume operationswhen the request processing latency is less than 50%.

TABLE 12 Example Adaptation Rule 3 opRule3 ruleID rid03 metricLinks/cse01/hwMetrics,/cse01/cseMetrics opMetrics diskIOUtilization > 75,dBReadLatency > max( ), dBWriteLatency > max( ), reqProcessingLatency >300 timeWindow null command suspend services CMDH, transaction, . . .resources AE, delivery, group, pollingChannel, subscription, . . .userPriorityLevels upl > 7 duration reqProcessingLatency < 50

All the rules described previously demonstrate the temporary suspensionof services or operations within the CSE. Rules may be created such thatservices or operations are disabled explicitly and may need acorresponding rule to re-enable the services or operations. Table 13 andTable 14 show companion rules in which all services, operations, anduser priority levels are disabled if the error rate within the CSEexceeds 50%. This condition signifies there may be some internal CSEproblems that are resulting in error responses being returned at a highrate than normal to user's requests. opRule4 is the rule that disablesCSE operations while opRule5 is used to re-enable CSE operations. Thismechanism may be used to give CSE administrators total control of CSEoperations to address potential internal server problems in which notimeframe exists for resolution. opRule4 may also be used to gracefullyterminate CSE operations before powering down the actual hardwareserver.

TABLE 13 Example Adaptation Rule 4 opRule4 ruleID rid04 metricLink/cse01/cseMetrics opMetrics errorRate > 50 timeWindow null commanddisable services all resources all userPriorityLevels all duration null

TABLE 14 Example Adaptation Rule 5 opRule5 ruleID rid05 metricLink/cse01/cseMetrics opMetrics errorRate < 2 timeWindow null command enableservices all resources all userPriorityLevels all duration null

In a oneM2M architecture, the procedures that are described above forthe SL interactions to a MANO system may be mapped to the oneM2M Mcnreference point. For example, the procedures may run on protocols suchas MPLS, OpenFlow, NETCONF, SNMP, CLI, PCEP, i2RS, etc.

The adaptation rules of the CSE can be readily displayed in a userinterface for CSE administrators to monitor if any rules are currentlyactive. FIG. 8 shows an example user interface listing all theadaptation rules created on a CSE. The user interface may have a columnof radial button to indicate whether a particular rule is activated. ACSE administrator can click on a Rule ID associated with a rule toobtain more information about the rule.

Any of the entities performing the steps illustrated in FIGS. 2-7, suchas the service layer, service layer device, service layer application,application entity, and the like, may be logical entities that may beimplemented in the form of software (i.e., computer-executableinstructions) stored in a memory of, and executing on a processor of, anapparatus configured for wireless and/or network communications or acomputer system such as those illustrated in FIG. 9C or FIG. 9D. Thatis, the method(s) illustrated in FIGS. 2-7 may be implemented in theform of software (i.e., computer-executable instructions) stored in amemory of an apparatus, such as the apparatus or computer systemillustrated in FIG. 9C or FIG. 9D, which computer executableinstructions, when executed by a processor of the apparatus, perform thesteps illustrated in FIGS. 2-7. It is also understood that anytransmitting and receiving steps illustrated in FIGS. 2-7 may beperformed by communication circuitry of the apparatus/entity undercontrol of the processor of the apparatus and the computer-executableinstructions (e.g., software) that it executes.

FIG. 9A is a diagram of an example machine-to machine (M2M), Internet ofThings (IoT), or Web of Things (WoT) communication system 10 in whichone or more disclosed embodiments may be implemented. Generally, M2Mtechnologies provide building blocks for the IoT/WoT, and any M2Mdevice, M2M gateway, M2M server, or M2M service platform may be acomponent or apparatus of the IoT/WoT as well as an IoT/WoT ServiceLayer, etc. Any of the entities illustrated in any of FIGS. 1-8 maycomprise a network apparatus of a communication system, such as the onesillustrated in FIGS. 9A-9D.

The service layer may be a functional layer within a network servicearchitecture. Service layers are typically situated above theapplication protocol layer such as HTTP, CoAP or MQTT and provide valueadded services to client applications. The service layer also providesan interface to core networks at a lower resource layer, such as forexample, a control layer and transport/access layer. The service layersupports multiple categories of (service) capabilities orfunctionalities including a service definition, service runtimeenablement, policy management, access control, and service clustering.Recently, several industry standards bodies, e.g., oneM2M, have beendeveloping M2M service layers to address the challenges associated withthe integration of M2M types of devices and applications intodeployments such as the Internet/Web, cellular, enterprise, and homenetworks. A M2M service layer may provide applications and/or variousdevices with access to a collection of or a set of the above-mentionedcapabilities or functionalities, supported by the service layer, whichmay be referred to as a CSE or SCL. A few examples include but are notlimited to security, charging, data management, device management,discovery, provisioning, and connectivity management which may becommonly used by various applications. These capabilities orfunctionalities are made available to such various applications via APIswhich make use of message formats, resource structures and resourcerepresentations defined by the M2M service layer. The CSE or SCL is afunctional entity that may be implemented by hardware and/or softwareand that provides (service) capabilities or functionalities exposed tovarious applications and/or devices (i.e., functional interfaces betweensuch functional entities) in order for them to use such capabilities orfunctionalities.

As shown in FIG. 9A, the M2M/IoT/WoT communication system 10 includes acommunication network 12. The communication network 12 may be a fixednetwork (e.g., Ethernet, Fiber, ISDN, PLC, or the like) or a wirelessnetwork (e.g., WLAN, cellular, or the like) or a network ofheterogeneous networks. For example, the communication network 12 may becomprised of multiple access networks that provide content such asvoice, data, video, messaging, broadcast, or the like to multiple users.For example, the communication network 12 may employ one or more channelaccess methods, such as code division multiple access (CDMA), timedivision multiple access (TDMA), frequency division multiple access(FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), and thelike. Further, the communication network 12 may comprise other networkssuch as a core network, the Internet, a sensor network, an industrialcontrol network, a personal area network, a fused personal network, asatellite network, a home network, or an enterprise network for example.

As shown in FIG. 9A, the M2M/IoT/WoT communication system 10 may includethe Infrastructure Domain and the Field Domain. The InfrastructureDomain refers to the network side of the end-to-end M2M deployment, andthe Field Domain refers to the area networks, usually behind an M2Mgateway. The Field Domain and Infrastructure Domain may both comprise avariety of different network apparatuses (e.g., servers, gateways,device, and the like) of the network. For example, the Field Domain mayinclude M2M gateways 14 and devices 18. It will be appreciated that anynumber of M2M gateway devices 14 and M2M devices 18 may be included inthe M2M/IoT/WoT communication system 10 as desired. Each of the M2Mgateway devices 14 and M2M devices 18 are configured to transmit andreceive signals, using communications circuitry, via the communicationnetwork 12 or direct radio link.

A M2M gateway 14 allows wireless M2M devices (e.g., cellular andnon-cellular) as well as fixed network M2M devices (e.g., PLC) tocommunicate either through operator networks, such as the communicationnetwork 12 or direct radio link. For example, the M2M devices 18 maycollect data and send the data, via the communication network 12 ordirect radio link, to an M2M application 20 or other M2M devices 18. TheM2M devices 18 may also receive data from the M2M application 20 or anM2M device 18. Further, data and signals may be sent to and receivedfrom the M2M application 20 via an M2M Service Layer 22, as describedbelow. M2M devices 18 and gateways 14 may communicate via variousnetworks including, cellular, WLAN, WPAN (e.g., Zigbee, 6LoWPAN,Bluetooth), direct radio link, and wireline for example. Example M2Mdevices include, but are not limited to, tablets, smart phones, medicaldevices, temperature and weather monitors, connected cars, smart meters,game consoles, personal digital assistants, health and fitness monitors,lights, thermostats, appliances, garage doors and other actuator-baseddevices, security devices, and smart outlets.

Referring to FIG. 9B, the illustrated M2M Service Layer 22 in the fielddomain provides services for the M2M application 20, M2M gateways 14,and M2M devices 18 and the communication network 12. It will beunderstood that the M2M Service Layer 22 may communicate with any numberof M2M applications, M2M gateways 14, M2M devices 18, and communicationnetworks 12 as desired. The M2M Service Layer 22 may be implemented byone or more network apparatuses of the network, which may compriseservers, computers, devices, or the like. The M2M Service Layer 22provides service capabilities that apply to M2M devices 18, M2M gateways14, and M2M applications 20. The functions of the M2M Service Layer 22may be implemented in a variety of ways, for example as a web server, inthe cellular core network, in the cloud, etc.

Similar to the illustrated M2M Service Layer 22, there is the M2MService Layer 22′ in the Infrastructure Domain. M2M Service Layer 22′provides services for the M2M application 20′ and the underlyingcommunication network 12 in the infrastructure domain. M2M Service Layer22′ also provides services for the M2M gateways 14 and M2M devices 18 inthe field domain. It will be understood that the M2M Service Layer 22′may communicate with any number of M2M applications, M2M gateways andM2M devices. The M2M Service Layer 22′ may interact with a Service Layerby a different service provider. The M2M Service Layer 22′ may beimplemented by one or more network apparatuses of the network, which maycomprise servers, computers, devices, virtual machines (e.g., cloudcomputing/storage farms, etc.) or the like.

Referring also to FIG. 9B, the M2M Service Layers 22 and 22′ provide acore set of service delivery capabilities that diverse applications andverticals may leverage. These service capabilities enable M2Mapplications 20 and 20′ to interact with devices and perform functionssuch as data collection, data analysis, device management, security,billing, service/device discovery, etc. Essentially, these servicecapabilities free the applications of the burden of implementing thesefunctionalities, thus simplifying application development and reducingcost and time to market. The Service Layers 22 and 22′ also enable M2Mapplications 20 and 20′ to communicate through various networks such asnetwork 12 in connection with the services that the Service Layers 22and 22′ provide.

The M2M applications 20 and 20′ may include applications in variousindustries such as, without limitation, transportation, health andwellness, connected home, energy management, asset tracking, andsecurity and surveillance. As mentioned above, the M2M Service Layer,running across the devices, gateways, servers and other networkapparatuses of the system, supports functions such as, for example, datacollection, device management, security, billing, locationtracking/geofencing, device/service discovery, and legacy systemsintegration, and provides these functions as services to the M2Mapplications 20 and 20′.

Generally, a Service Layer, such as the Service Layers 22 and 22′illustrated in FIG. 9B, defines a software middleware layer thatsupports value-added service capabilities through a set of ApplicationProgramming Interfaces (APIs) and underlying networking interfaces. Boththe ETSI M2M and oneM2M architectures define a Service Layer. ETSI M2M'sService Layer is referred to as the Service Capability Layer (SCL). TheSCL may be implemented in a variety of different nodes of the ETSI M2Marchitecture. For example, an instance of the Service Layer may beimplemented within an M2M device (where it is referred to as a deviceSCL (DSCL)), a gateway (where it is referred to as a gateway SCL (GSCL))and/or a network node (where it is referred to as a network SCL (NSCL)).The oneM2M Service Layer supports a set of Common Service Functions(CSFs) (i.e., service capabilities). An instantiation of a set of one ormore particular types of CSFs is referred to as a Common Services Entity(CSE) which may be hosted on different types of network nodes (e.g.,infrastructure node, middle node, application-specific node). The ThirdGeneration Partnership Project (3GPP) has also defined an architecturefor machine-type communications (MTC). In that architecture, the ServiceLayer, and the service capabilities it provides, are implemented as partof a Service Capability Server (SCS). Whether embodied in a DSCL, GSCL,or NSCL of the ETSI M2M architecture, in a Service Capability Server(SCS) of the 3GPP MTC architecture, in a CSF or CSE of the oneM2Marchitecture, or in some other node of a network, an instance of theService Layer may be implemented as a logical entity (e.g., software,computer-executable instructions, and the like) executing either on oneor more standalone nodes in the network, including servers, computers,and other computing devices or nodes, or as part of one or more existingnodes. As an example, an instance of a Service Layer or componentthereof may be implemented in the form of software running on a networkapparatus (e.g., server, computer, gateway, device or the like) havingthe general architecture illustrated in FIG. 9C or FIG. 9D describedbelow.

Further, the methods and functionalities described herein may beimplemented as part of an M2M network that uses a Service OrientedArchitecture (SOA) and/or a Resource-Oriented Architecture (ROA) toaccess services.

FIG. 9C is a block diagram of an example hardware/software architectureof an apparatus of a network, such as one of the entities illustrated inFIGS. 1-8, which may operate as an M2M server, gateway, device, or othernetwork apparatus in an M2M network such as that illustrated in FIGS. 9Aand 9B. As shown in FIG. 9D, the network apparatus 30 may include aprocessor 32, non-removable memory 44, removable memory 46, aspeaker/microphone 38, a keypad 40, a display, touchpad, and/orindicators 42, a power source 48, a global positioning system (GPS)chipset 50, and other peripherals 52. The network apparatus 30 may alsoinclude communication circuitry, such as a transceiver 34 and atransmit/receive element 36. It will be appreciated that the networkapparatus 30 may include any sub-combination of the foregoing elementswhile remaining consistent with an embodiment. This network apparatusmay be an apparatus that implements the methods for the adaptive controlof service layer operations described herein, such as the methodsoperations illustrated and described in relation to FIGS. 2-7.

The processor 32 may be a general purpose processor, a special purposeprocessor, a conventional processor, a digital signal processor (DSP), aplurality of microprocessors, one or more microprocessors in associationwith a DSP core, a controller, a microcontroller, Application SpecificIntegrated Circuits (ASICs), Field Programmable Gate Array (FPGAs)circuits, any other type of integrated circuit (IC), a state machine,and the like. In general, the processor 32 may executecomputer-executable instructions stored in the memory (e.g., memory 44and/or memory 46) of the network apparatus in order to perform thevarious required functions of the network apparatus. For example, theprocessor 32 may perform signal coding, data processing, power control,input/output processing, and/or any other functionality that enables thenetwork apparatus 30 to operate in a wireless or wired environment. Theprocessor 32 may run application-layer programs (e.g., browsers) and/orradio access-layer (RAN) programs and/or other communications programs.The processor 32 may also perform security operations such asauthentication, security key agreement, and/or cryptographic operations,such as at the access-layer and/or application layer for example.

As shown in FIG. 9C, the processor 32 is coupled to its communicationcircuitry (e.g., transceiver 34 and transmit/receive element 36). Theprocessor 32, through the execution of computer executable instructions,may control the communication circuitry in order to cause the networkapparatus 30 to communicate with other network apparatuses via thenetwork to which it is connected. In particular, the processor 32 maycontrol the communication circuitry in order to perform the transmittingand receiving steps described herein (e.g., in FIGS. 2-7) and in theclaims. While FIG. 9C depicts the processor 32 and the transceiver 34 asseparate components, it will be appreciated that the processor 32 andthe transceiver 34 may be integrated together in an electronic packageor chip.

The transmit/receive element 36 may be configured to transmit signalsto, or receive signals from, other network apparatuses, including M2Mservers, gateways, device, and the like. For example, in an embodiment,the transmit/receive element 36 may be an antenna configured to transmitand/or receive RF signals. The transmit/receive element 36 may supportvarious networks and air interfaces, such as WLAN, WPAN, cellular, andthe like. In an embodiment, the transmit/receive element 36 may be anemitter/detector configured to transmit and/or receive IR, UV, orvisible light signals, for example. In yet another embodiment, thetransmit/receive element 36 may be configured to transmit and receiveboth RF and light signals. It will be appreciated that thetransmit/receive element 36 may be configured to transmit and/or receiveany combination of wireless or wired signals.

In addition, although the transmit/receive element 36 is depicted inFIG. 9C as a single element, the network apparatus 30 may include anynumber of transmit/receive elements 36. More specifically, the networkapparatus 30 may employ MIMO technology. Thus, in an embodiment, thenetwork apparatus 30 may include two or more transmit/receive elements36 (e.g., multiple antennas) for transmitting and receiving wirelesssignals.

The transceiver 34 may be configured to modulate the signals that are tobe transmitted by the transmit/receive element 36 and to demodulate thesignals that are received by the transmit/receive element 36. As notedabove, the network apparatus 30 may have multi-mode capabilities. Thus,the transceiver 34 may include multiple transceivers for enabling thenetwork apparatus 30 to communicate via multiple RATs, such as UTRA andIEEE 802.11, for example.

The processor 32 may access information from, and store data in, anytype of suitable memory, such as the non-removable memory 44 and/or theremovable memory 46. For example, the processor 32 may store sessioncontext in its memory, as described above. The non-removable memory 44may include random-access memory (RAM), read-only memory (ROM), a harddisk, or any other type of memory storage device. The removable memory46 may include a subscriber identity module (SIM) card, a memory stick,a secure digital (SD) memory card, and the like. In other embodiments,the processor 32 may access information from, and store data in, memorythat is not physically located on the network apparatus 30, such as on aserver or a home computer. The processor 32 may be configured to controllighting patterns, images, or colors on the display or indicators 42 toreflect the status of an apparatus or configure an apparatus, and inparticular underlying networks, applications, or other services incommunication with the network apparatus. In one embodiment, thedisplay/indicators 42 may present the graphical user interfaceillustrated in FIG. 9D and described herein.

The processor 32 may receive power from the power source 48, and may beconfigured to distribute and/or control the power to the othercomponents in the network apparatus 30. The power source 48 may be anysuitable device for powering the network apparatus 30. For example, thepower source 48 may include one or more dry cell batteries (e.g.,nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH),lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

The processor 32 may also be coupled to the GPS chipset 50, which isconfigured to provide location information (e.g., longitude andlatitude) regarding the current location of the network apparatus 30. Itwill be appreciated that the network apparatus 30 may acquire locationinformation by way of any suitable location-determination method whileremaining consistent with an embodiment.

The processor 32 may further be coupled to other peripherals 52, whichmay include one or more software and/or hardware modules that provideadditional features, functionality and/or wired or wirelessconnectivity. For example, the peripherals 52 may include varioussensors such as an accelerometer, biometrics (e.g., fingerprint)sensors, an e-compass, a satellite transceiver, a sensor, a digitalcamera (for photographs or video), a universal serial bus (USB) port orother interconnect interfaces, a vibration device, a televisiontransceiver, a hands free headset, a Bluetooth® module, a frequencymodulated (FM) radio unit, a digital music player, a media player, avideo game player module, an Internet browser, and the like.

The network apparatus 30 may be embodied in other apparatuses ordevices, such as a sensor, consumer electronics, a wearable device suchas a smart watch or smart clothing, a medical or eHealth device, arobot, industrial equipment, a drone, a vehicle such as a car, truck,train, or airplane. The network apparatus 30 may connect to othercomponents, modules, or systems of such apparatuses or devices via oneor more interconnect interfaces, such as an interconnect interface thatmay comprise one of the peripherals 52.

FIG. 9C is a block diagram of an example computing system 90 which mayalso be used to implement one or more network apparatuses of a network,such as the entities illustrated in FIGS. 1-8 and described herein,which may operate as an M2M server, gateway, device, or other networkapparatus in an M2M network such as that illustrated in FIGS. 9A and 9B.

Computing system 90 may comprise a computer or server and may becontrolled primarily by computer readable instructions, which may be inthe form of software, wherever, or by whatever means such software isstored or accessed. Such computer readable instructions may be executedwithin a processor, such as central processing unit (CPU) 91, to causecomputing system 90 to do work. In many known workstations, servers, andpersonal computers, central processing unit 91 is implemented by asingle-chip CPU called a microprocessor. In other machines, the centralprocessing unit 91 may comprise multiple processors. Coprocessor 81 isan optional processor, distinct from main CPU 91, that performsadditional functions or assists CPU 91. CPU 91 and/or coprocessor 81 mayreceive, generate, and process data related to the disclosed systems andmethods for E2E M2M Service Layer sessions, such as receiving sessioncredentials or authenticating based on session credentials.

In operation, CPU 91 fetches, decodes, and executes instructions, andtransfers information to and from other resources via the computer'smain data-transfer path, system bus 80. Such a system bus connects thecomponents in computing system 90 and defines the medium for dataexchange. System bus 80 typically includes data lines for sending data,address lines for sending addresses, and control lines for sendinginterrupts and for operating the system bus. An example of such a systembus 80 is the PCI (Peripheral Component Interconnect) bus.

Memories coupled to system bus 80 include random access memory (RAM) 82and read only memory (ROM) 93. Such memories include circuitry thatallows information to be stored and retrieved. ROMs 93 generally containstored data that cannot easily be modified. Data stored in RAM 82 may beread or changed by CPU 91 or other hardware devices. Access to RAM 82and/or ROM 93 may be controlled by memory controller 92. Memorycontroller 92 may provide an address translation function thattranslates virtual addresses into physical addresses as instructions areexecuted. Memory controller 92 may also provide a memory protectionfunction that isolates processes within the system and isolates systemprocesses from user processes. Thus, a program running in a first modemay access only memory mapped by its own process virtual address space;it cannot access memory within another process's virtual address spaceunless memory sharing between the processes has been set up.

In addition, computing system 90 may contain peripherals controller 83responsible for communicating instructions from CPU 91 to peripherals,such as printer 94, keyboard 84, mouse 95, and disk drive 85.

Display 86, which is controlled by display controller 96, is used todisplay visual output generated by computing system 90. Such visualoutput may include text, graphics, animated graphics, and video. Display86 may be implemented with a CRT-based video display, an LCD-basedflat-panel display, gas plasma-based flat-panel display, or atouch-panel. Display controller 96 includes electronic componentsrequired to generate a video signal that is sent to display 86. Display86, in combination with the computer-executable instructions executed byCPU 91, may generate and operate the graphical user interfaceillustrated and described in FIG. 9D and its accompanying description.

Further, computing system 90 may contain communication circuitry, suchas for example a network adaptor 97, that may be used to connectcomputing system 90 to an external communications network, such asnetwork 12 of FIG. 9A-9D, to enable the computing system 90 tocommunicate with other apparatuses of the network. The communicationcircuitry, alone or in combination with the CPU 91, may be used toperform the transmitting and receiving steps described herein (e.g., inFIGS. 2-7) and in the claims.

It is understood that any or all of the systems, methods and processesdescribed herein may be embodied in the form of computer executableinstructions (i.e., program code) stored on a computer-readable storagemedium which instructions, when executed by a machine, such as anapparatus of an M2M network, including for example an M2M server,gateway, device or the like, perform and/or implement the systems,methods and processes described herein. Specifically, any of the steps,operations or functions described above may be implemented in the formof such computer executable instructions. Computer readable storagemedia include both volatile and nonvolatile, removable and non-removablemedia implemented in any non-transitory (i.e., tangible or physical)method or technology for storage of information, but such computerreadable storage media do not include signals. Computer readable storagemedia include, but are not limited to, RAM, ROM, EEPROM, flash memory orother memory technology, CD-ROM, digital versatile disks (DVD) or otheroptical disk storage, magnetic cassettes, magnetic tape, magnetic diskstorage or other magnetic storage devices, or any other tangible orphysical medium which may be used to store the desired information andwhich may be accessed by a computer.

The following is a list of acronyms relating to service layertechnologies that may appear in the above description. Unless otherwisespecified, the acronyms used herein refer to the corresponding termlisted below:

ACP Access Control Policy AE Application Entity CSE Common ServicesEntity CSF Common Services Function DM Device Management GUI GraphicalUser Interface IoT Internet of Things i2RS Interface to the RoutingSystem MANO Management and Orchestration MPLS Multiprotocol LabelSwitching M2M Machine-to-Machine NETCONF Network Configuration ProtocolPCEP Path Computational Element Protocol PoA Point of Access RL ResourceLevels SL Service Layer SNMP Simple Network Management Protocol

The following is a list of terms and definitions relating to servicelayer technologies that may appear in the above description. Unlessotherwise specified, the terms and definitions used herein refer to thecorresponding term listed below:

Term Definition Adaptive The mechanism in which a Service Layer'scontrol operations can be adjusted to account for changing serverconditions. Adjustments typically involve suspending or disablingcertain services or operations to limit the loading of the ServiceLayer. It may also involve resuming or enabling services or operationsas the Service Layer recovers more server resources. Memory and Notethat we use the term memory and storage Storage somewhatinterchangeablyin this paper, however, sometimes there can be distinction between thetwo terms. Storage often refers to memory that is used to store datavalues and memory can generically refer to storage or memory that isused to store executable code. Server These are physical or virtualresources present in resources the operations of a Service Layer thatusually are associated with hardware. Physical resources may consist ofhardware CPU, memory, storage, network connectivity, etc. and virtualresources can be virtual machines or containers and network functionsthat realizes a Service Layer, for example, in the cloud. Service LayerA term used to signify the Service Layer is running adaptation in areduced, functional state from its normal operations. This may be aresult of the proposed adaptive control that is activated by one or moreSL adaptation rules.

This written description uses examples to disclose the invention,including the best mode, and also to enable any person skilled in theart to practice the invention, including making and using any devices orsystems and performing any incorporated methods. The patentable scope ofthe invention is defined by the claims, and may include other examplesthat occur to those skilled in the art. Such other examples are intendedto be within the scope of the claims if they have elements that do notdiffer from the literal language of the claims, or if they includeequivalent elements with insubstantial differences from the literallanguage of the claims.

What is claimed:
 1. A method implemented in a service layer entity of acommunications network, the method comprising: activating, at theservice layer entity, one or more adaptation rules for modifying one ormore characteristics of the service layer entity based on one or moreoperational metrics of the service layer entity, wherein the operationalmetrics of the service layer entity comprise one or more service layermetrics; receiving, from another entity in communication with theservice layer entity, a request to perform an operation at the servicelayer entity; determining, at the service layer entity and based on theone or more adaptation rules, that the operation is not capable of beingexecuted by the service layer entity; and transmitting, by the servicelayer entity, a request for additional resources to be utilized by theservice layer entity.
 2. The method of claim 1, wherein the servicelayer metrics comprise one or more of a resource discovery latency, asemantic query latency, a database read latency, a database writelatency, a request processing latency, a throughput, an error rate, anumber of pending requests, a number of subscription resources, and anotification rate.
 3. The method of claim 1, wherein the request for theadditional resources comprises at least one of an indication of the typeof additional resources needed, how long the additional resources areneeded, and a reason for requesting the additional resources.
 4. Themethod of claim 3, wherein the type of the additional resourcescomprises one or more of additional storage, additional memory,additional processing cycles, lower latency storage and lower latencymemory.
 5. The method of claim 1, further comprising receiving aresponse that indicates one or more of whether the additional resourceswill be provided, when the additional resources will be provided, howlong the additional resources will be provided for, and a costassociated with receiving the additional resources.
 6. The a method ofclaim 1, further comprising receiving a response indicating that theservice layer entity should move to a different physical platform. 7.The method of claim 1, wherein the request for the additional resourcesis sent to a management and orchestration system.
 8. An apparatuscomprising a processor and a memory, the memory storingcomputer-executable instructions which, when executed by the processor,implement a service layer entity of a communications network and causethe service layer entity to perform operations comprising: activating,at the service layer entity, one or more adaptation rules for modifyingone or more characteristics of the service layer entity based on one ormore operational metrics of the service layer entity, wherein theoperational metrics of the service layer entity comprise one or moreservice layer metrics; receiving, from another entity in communicationwith the service layer entity, a request to perform an operation at theservice layer entity; determining, at the service layer entity and basedon the one or more adaptation rules, that the operation is not capableof being executed by the service layer entity; and transmitting, by theservice layer entity, a request for additional resources to be utilizedby the service layer entity.
 9. The apparatus of claim 8, wherein theservice layer metrics comprise one or more of a resource discoverylatency, a semantic query latency, a database read latency, a databasewrite latency, a request processing latency, a throughput, an errorrate, a number of pending requests, a number of subscription resources,and a notification rate.
 10. The apparatus of claim 8, wherein therequest for the additional resources comprises at least one of anindication of the type of additional resources needed, how long theadditional resources are needed, and a reason for requesting theadditional resources.
 11. The apparatus of claim 10, wherein the type ofthe additional resources comprises one or more of additional storage,additional memory, additional processing cycles, lower latency storageand lower latency memory.
 12. The apparatus of claim 8, wherein theinstructions when executed further cause the service layer entity toperform operations comprising receiving a response that indicates one ormore of whether the additional resources will be provided, when theadditional resources will be provided, how long the additional resourceswill be provided for, and a cost associated with receiving theadditional resources.
 13. The apparatus of claim 8, wherein theinstructions when executed further cause the service layer entity toperform operations comprising receiving a response indicating that theservice layer entity should move to a different physical platform. 14.The apparatus of claim 8, wherein the request for the additionalresources is sent to a management and orchestration system.
 15. Acomputer-readable storage medium storing computer-executableinstructions which, when executed by a processor, implement a servicelayer entity of a communications network and cause the service layerentity to perform operations comprising: activating, at the servicelayer entity, one or more adaptation rules for modifying one or morecharacteristics of the service layer entity based on one or moreoperational metrics of the service layer entity, wherein the operationalmetrics of the service layer entity comprise one or more service layermetrics; receiving, from another entity in communication with theservice layer entity, a request to perform an operation at the servicelayer entity; determining, at the service layer entity and based on theone or more adaptation rules, that the operation is not capable of beingexecuted by the service layer entity; and transmitting, by the servicelayer entity, a request for additional resources to be utilized by theservice layer entity.
 16. The computer-readable storage medium of claim15, wherein the service layer metrics comprise one or more of a resourcediscovery latency, a semantic query latency, a database read latency, adatabase write latency, a request processing latency, a throughput, anerror rate, a number of pending requests, a number of subscriptionresources, and a notification rate.
 17. The computer-readable storagemedium of claim 15, wherein the request for the additional resourcescomprises at least one of an indication of the type of additionalresources needed, how long the additional resources are needed, and areason for requesting the additional resources.
 18. Thecomputer-readable storage medium of claim 17, wherein the type of theadditional resources comprises one or more of additional storage,additional memory, additional processing cycles, lower latency storageand lower latency memory.
 19. The computer-readable storage medium ofclaim 15, wherein the instructions when executed further cause theservice layer entity to perform operations comprising receiving aresponse that indicates one or more of whether the additional resourceswill be provided, when the additional resources will be provided, howlong the additional resources will be provided for, and a costassociated with receiving the additional resources.
 20. Thecomputer-readable storage medium of claim 15, wherein the instructionswhen executed further cause the service layer entity to performoperations comprising receiving a response indicating that the servicelayer entity should move to a different physical platform.